Service Providers worldwide are increasingly concerned over the rising degree of network capacity resources consumed by their subscribers. New Internet applications and increasingly richer media content generate a voracious appetite for network capacity resources. Meanwhile, despite the increasing demand on network capacity resources, subscribers' expectations for enhanced service experience continues to increase as well.
Rising subscriber use of network capacity resources within the broadband access networks of cable broadband service providers impacts the cable broadband service providers' Data Over Cable Service Interface Specification (DOCSIS) infrastructures. With the introduction of the DOCSIS 3.0 standard, network device support for Internet Protocol Detail Record (IPDR) is now mandatory. IDPR enables visibility into DOCSIS Service Flows which carry subscriber data across broadband access networks using the DOCSIS 2.0 or 3.0 standard. With cable broadband service providers deploying subscriber usage metering, acceptable use policies, and usage based billing systems based on information gathered using IPDR, the reliable collection and accurate analysis of IPDR data is critical.
Various complex factors influence the behavior of IPDR-based measurements when applied to subscriber usage metering scenarios in DOCSIS networks. One exemplary class of network event measurements is a standard data model referred to as IPDR Subscriber Accounting Management Interface Specification (SAMIS) data. Generally, cable broadband service providers view SAMIS data described in the DOCSIS specifications as a preferred source of data from which to determine subscriber usage in DOCSIS networks. However, without appropriate methods and systems for evaluating the SAMIS data to calculate subscriber usage, collecting and analyzing SAMIS data can be unreliable and inaccurate.
Cable broadband operators attempting to implement IPDR-based subscriber usage metering and billing systems have been met by an observant and critical subscriber and consumer advocacy community. Discrepancies in subscriber usage results that were found when comparing values collected by service providers to those taken independently by their subscribers have caused concern in the broadband industry. Accordingly, cable broadband service providers can be expected to face increasing scrutiny as Internet metering and usage based billing systems become more prevalent.
A related area of concern exists regarding what types of Internet traffic are included in the calculation of subscriber usage values. While the majority of Internet traffic sent to or from a subscriber is consumed by end-user applications, additional traffic is generated on the network for management, maintenance, and protocol overhead. It is generally accepted that this administrative traffic should not be included in the calculation of a subscriber's usage values.
The methods and systems described herein for collecting and managing network data enable cable broadband service providers to reliably collect and accurately analyze, in a timely manner, subscriber Internet usage values based on IPDR data from DOCSIS networks.
For simplicity and clarity of illustration, the drawing figures illustrate the general manner of construction, and descriptions and details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the invention. Additionally, elements in the drawing figures are not necessarily drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of embodiments of the present invention. The same reference numerals in different figures denote the same elements.
The terms “first,” “second,” “third,” “fourth,” and the like in the description and in the claims, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms “include,” and “have,” and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, device, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, system, article, device, or apparatus.
The terms “left,” “right,” “front,” “back,” “top,” “bottom,” “over,” “under,” and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.
The terms “couple,” “coupled,” “couples,” “coupling,” and the like should be broadly understood and refer to connecting two or more elements or signals, electrically, mechanically and/or otherwise. Two or more electrical elements may be electrically coupled together, but not be mechanically or otherwise coupled together; two or more mechanical elements may be mechanically coupled together, but not be electrically or otherwise coupled together; two or more electrical elements may be mechanically coupled together, but not be electrically or otherwise coupled together. Coupling may be for any length of time, e.g., permanent or semi-permanent or only for an instant.
“Electrical coupling” and the like should be broadly understood and include coupling involving any electrical signal, whether a power signal, a data signal, and/or other types or combinations of electrical signals. “Mechanical coupling” and the like should be broadly understood and include mechanical coupling of all types.
The absence of the word “removably,” “removable,” and the like near the word “coupled,” and the like does not mean that the coupling, etc. in question is or is not removable.
The term “database” as used herein refers to a location for storing information or data, and/or a mechanism for storing information or data. As such, the term “database” can be used interchangeably with related terms, such as, for example, data storage, data store, etc.
The term “normalize” as used herein refers to evaluating a record and producing a “normalized” representation consisting of a common record format. For example, non-normalized network data may be based on differing protocol versions and/or vendor implementations. As such, even in situations where common and standard schemas are present, the structural, syntactical, and logical meaning of common fields can be different across different vendor implementations. Accordingly, this data can be normalized to a common record format such that data from multiple or all of the different protocol versions and/or vendor implementations has a common schema.
The term “record stream” as used herein refers to a series of data records. These data records can have an associated timestamp, but do not necessarily arrive at a location in temporal order according to their timestamp.
The term “service flow” as used herein refers to a flow of end-user data with a common quality of service (QoS) and other common characteristics being monitored by the system.
The term “semantic routing” as used herein refers to routing information based on its characteristics, such as a source and/or format. For example, semantic routing can be used to route a data stream to a particular software application based on its source and/or format. If the source or data format of the data stream were to change, the data stream could then be routed to a different software application.
The term “semantic routing rule set” as used herein refers to a set of rules or criteria which reflect the meaning of the data and by which routing decisions are made. Typically, multiple semantic routing rule sets are provided to facilitate different routing for different data sets.
The term “template” as used herein refers to a set of fields making up an individual data record. A template can be used for decoding or encoding individual data records. A set of records in the same data collection session generally can share the same template.